Application No. 10/577,641 

Reply to Office Action dated March 16, 2010 



REMARKS 

This is a Response to the Final Office Action mailed March 16, 2010, in which a 
three (3) month Shortened Statutory Period for Response has been set, due to expire June 16, 
2010. Thirty (30) claims, including eight (8) independent claims, were paid for in the 
application. Claim 2 is canceled herein. Claims 1,3, 5-8, and 12 are amended herein. No new 
matter has been added to the application. The Director is authorized to charge any additional 
fees due by way of this Amendment, or credit any overpayment, to our Deposit Account No. 19- 
1090. Claims 1 and 3-26 are pending. 

35 U.S.C. m2(h) Rejections 

Claims 1-26 were rejected under 35 U.S.C. §102(b) as being anticipated by U.S. 
Patent No. 6,751,209 issued to Hamiti et al. (hereinafter "Hamiti"). 

Claims 1 and 12 

1) Claims 1 and 12 have been amended to include particular limitations 
corresponding to canceled claim 2. However, Applicants submit that even previous to the 
present amendment, claims 1 and 12 were not anticipated by Hamiti for at least the reasons 
presented in Applicants' previous response. 

2) The office action alleges that Hamiti discloses ''marking a compressed header 
and an RTP payload" relying on Figure 5 and the passage at col. 7, lines 8-9 of Hamiti, 

Although there is a marker bit in Hamiti, the passage at col. 5, lines 1 8-24 of 
Hamiti explains that "Field 314 includes a marker bit that is optionally used to mark important 
events in the packet stream, for instance, the beginning of a speech burst, or a last packet in a 
video fi-ame." Therefore, the marker bit of Hamiti is not to mark a compressed header and an 
RTP payload as recited in the claims. Furthermore, Hamiti states, if used, the marker bit of 
"needs to be transmitted in the compressed header" (see col. 5, lines 21-22 of Hamiti), and thus it 
can not be used to mark the compressed header if it is being transferred within the compressed 
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header. In fact, Hamiti fails to teach or even suggest marking the compressed header and RTP 
payload. 

Page 12 of the Response to Arguments section of the office action states ". ..field 
52 (fig. 5) indicates the marker bit of the compressed RTP header, col. 7, lines 9-1 1 ." Although 
col. 7, lines 9-10 of Hamiti mention a "marker bit of the RTP header," Applicants submit that 
this indicates that the marker bit of Hamiti is inside RTP header to mark important events in the 
packet stream as shown above, not that it marks the RTP header. 

3) The office action alleges that Hamiti discloses "separating the compressed 
header from the RTP payload based on said marking, to respectively form PDCP layer PDUs 
before mapping them to different RLC entities " relying on the RTP part of Figure 3 and the 
passages at col. 4, lines 58-64 and col. 5, lines 20-22 of Hamiti. 

The passage at col. 4, lines 58-64 reads "[t]he access network SNDC function 
provides to the network layer a service for transferring a minimum amount of data between the 
SGSN and MS through different compression techniques. GPRS provides a procedure, which is 
implemented in connection with the service negotiation, for the MS and the SGSN to agree on 
the compression algorithm to be used in the session." The passage at col. 5, lines 20-22 reads 
"[i]f the marker bit 3 1 4 is used it needs to be transmitted in the compressed header. Field 3 1 6 
indicating the sequence number and field 317 indicating the time stamp will change for all RTP 
Packets." These passages are silent regarding the above definition of the claims. Moreover, 
Applicants' representative has noticed that the passage at col. 12, lines 17-19 of Hamiti recites 
"[a]n SNDCP packet comprising the compressed header and the RTP payload is sent to the 
decompressor". (Emphasis added.) 

Page 13 of the Response to Arguments section of the office action states ". . .in 
the compressed RTP header shown in figure 5, including the marker 52, the compressed header 
shall include the length octet and the bits 53 and the last octet are used to indicate the length of 
the RTP payload." Applicants submit that including bits in a packet to indicate length of the 
payload is not the same as, according to claims 1 and 12, " separating the compressed header 
from the RTP payload based on said marking." In fact, what the office action alleges discloses 
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the "marking'' is bit 52 shown in Fig. 5 of Hamiti, which is not mentioned in Hamiti as being 
used at all in relation to determining the "bits 53" and the "last octet" in Figure 5 of Hamiti 
indicating RTP payload length. 

4) The office action also alleges that Hamiti teaches "PDU-size adapting the 
plurality of different header compression lengths of the header-compressed RTP packets, so as to 
comply with said lengths and length types required by the system" relying on passages at col. 7, 
lines 1-6 and col. 9, lines 50-54 of Hamiti. 

As claimed, the ''plurality of different header compression lengths of the header- 
compressed RTP packets" are PDU-size adapted to several pre-configured size-fixed length, so 
that the TFCI decoding can be ensured and that the physical layer processing can be facilitated 
by processing such header-compressed RTP packets of pre-configured size-fixed lengths. 

However, Hamiti, col. 9, lines 50-54 only discloses that two different SN-PDU 
formats are defined for acknowledged/unacknowledged data transfer. In particular, these two 
formats are used for correctly decompressing the identification data (/.e., RTP sequence number, 
RTP time stamp and IP identification, see fields 316, 317 and 335 of Figure 3) from the 
transferred compressed header in acknowledged and unacknowledged data transfer, respectively. 
Hamiti, col. 9, lines 40-42 and col. 9, line 59 to col. 10, line 22. 

Since Hamiti defines the two SN-PDU formats based on their ACK mechanism, 
compressed packets are filled in a PDU format depending on whether they are of 
acknowledged/unacknowledged data transfer, which has nothing to do with size adapting the 
packets into different lengths as required by the system. In contrast, as claimed, the compressed 
header- packets are adapted to different sizes (i.e., lengths) as required by the system, so as to 
facilitate physical layer processing. 

Page 12 of the Response to Arguments section of the office action, referring to 
col. 6, lines 53-67 of Hamati, state ". . .the header fields. . .have different lengths chosen to 
provide transmission of the information; therefore the compressed header packets are adapted to 
various lengths." However, Applicants submit that as claimed, the compressed header-packets 
are adapted to different sizes, "so as to facilitate physical layer processing", which is more 
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specific than to generally "provide transmission of the information," and thus, Hamati does not 
disclose the limitations as claimed. 

In view of the above, Hamiti does not teach or suggest the limitations recited in 
claim 1 . Neither does Hamiti teach or suggest the limitations recited in claim 12. 

Claims 13 and 21 

1) The office action alleges that Hamiti discloses "marking a compressed header 
and an RTPpayload" relying on Figure 5 and the passage at col. 7, lines 8-9 of Hamiti. As 
explained above, Hamiti does not teach or suggest these elements. 

2) The office action alleges that Hamiti discloses " separating the compressed 
header from the RTF payload based on said marking, to respectively fiyrm PDCP layer PDUs 
beft)re mapping them to different RLC entities" relying on the RTP part of Figure 3 and the 
passages at col. 4, lines 58-64 and col. 5, lines 20-22 of Hamiti. As explained above, Hamiti 
does not teach or suggest these elements. 

In view of the above, Hamiti does not teach or suggest the limitations recited in 
claim 13. Neither does Hamiti teach or suggest the limitations recited in claim 21 . 

Claims 20 and 22 

1) The office action alleges that Hamiti discloses "a compressed header of the 
header-compressed packet is separated from an RTP payload thereof at the transmitting end to 
form different PDCP layer PDUs that are transmitted on different RLC entities" relying on 
Figure 1, element 16, the passage at col. 4, lines 24-31, and the passage at col. 8, lines 41-42 of 
Hamiti. 

As explained above, Hamiti does not teach or suggest "a compressed header of 
the header-compressed packet is separated from an RTP payload thereof at the transmitting end 
to form different PDCP layer PDUs. " In addition, Hamiti does not teach or suggest that the 
formed PDUs "are transmitted on different RLC entities" as recited by claims 20 and 22. Figure 
1 of Hamiti merely illustrates the accumulation of header overhead by the different layers in 
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transmission of one voice frame over a wireless IP connection, and does not show ^'separating 
the compressed header from the RTP payload at the transmitting end to fi)rm different PDCP 
layer PDUs that are transmitted on different RLC entities.^'' 

2) The office action further alleges that Hamiti discloses " combining the extracted 
compressed header with the RTP payload^ relying on the passages at col. 8, lines 63-67 and col. 
9, lines 1-14 of Hamiti. 

However, what is taught in those passages of Hamiti is "for packets that might 
disturb the compression, e.g. ones that arrive very late to the compressor and might therefore 
potentially disrupt the order of updating the compression information, a corrective action in the 
compressor will result." These teachings only relate to managing whether to recover or 
regenerate a late-arriving packet, while being totally silent with respect to the recited ''''combining 
the extracted compressed header with the RTP payload' of the claims. 

In view of the above, Hamiti does not teach or suggest the limitations recited in 
claim 20. Neither does Hamiti teach or suggest the limitations recited in claim 22. 

Claims 23 and 26 

1) The office action alleges that Hamiti discloses "monitoring whether or not the 
bandwidth requirement of the RTP packet exceeds a predetermined value", relying on passages 
at col. 4, lines 31-65 of Hamiti (the office action states on page 13 that col. 7, lines 31-65 were 
erroneously cited in the previous office action). 

The passage at col. 4, lines 31-65 of Hamiti disclose that the cumulative overhead 
of an RTP packet is very large when the packet is encapsulated into various layers. Col. 4, lines 
3 1-35 of Hamiti state, "Already in IP layer the protocol overhead is 40 bytes and the bandwidth 
utilization is around 33% when G723.1 encoder is used." Although Hamiti shows one example 
statistic bandwidth utilization of a particular packet, Hamiti does not disclose a predetermined 
value or utilizing a predetermined value and thus does not disclose "monitoring whether or not 
the bandwidth requirement of the RTP packet exceeds a predetermined value." 
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2) The office action further alleges that Hamiti discloses 'Hfthe bandwidth 
requirement of the RTF packet exceeds the predetermined value and there is an RTCP packet to 
be transmitted, buffering the RTCP packet relying on passages at col. 4, lines 31-65 of Hamiti 

First, Hamiti is totally silent regarding affecting the transmission of an RTCP and 
RTP packet based on a bandwidth requirement. Second, it seems that the Office considers "a 
number of header data fields that remain constant during the data transfer" of Hamiti as 
equivalent to the "RTCP packet" of the present claims. However, "i?rCP is used for 
periodically transmitting such information as quality parameters of the media transmission." 
See, "BACKGROUND OF THE INVENTION, para. 2 of the present application (emphasis 
added). In contrast, "a number of header data fields that remain constant during the data 
transfer" of Hamiti refers to the header data fields that remain constant during a session. Hamiti, 
col. 5, line 1 to col. 6, line 4. Notably, none of which header data fields are used to periodically 
transmit such information as quality parameters of the media transmission, as the RTCP packet 
does. Therefore, "a number of header data fields that remain constant during the data transfer" 
of Hamiti is not the same as, or equivalent to, the recited "RTCP packet." 

Additionally, Hamiti does not even mention "buffering the RTCP packet." 

3) Since Hamiti does not disclose the above elements of claims 23 and 26, Hamiti 
cannot disclose ''continuously monitoring the bandwidth requirement of the RTP packet, and 
transmitting the RTCP packet when the bandwidth requirement is lower than the predetermined 
value". 

In light of the above, the pending independent claims, as well as the dependent 
claims, are not anticipated by Hamiti, and thus are patentable. 

Conclusion 

Applicants respectfiilly submit that the pending claims are in condition for 
allowance. Any remarks in support of patentability of one claim should not be imputed to any 
other claim, even if similar terminology is used. Any remarks referring to only a portion of a 
claim should not be understood to base patentability on that portion; rather, patentability must 
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rest on each claim taken as a whole. A number of clarifying amendments have also been made 
to the above claim set. Applicants do not acquiesce to each of the Examiner's rejections and to 
each of the Examiner's assertions regarding what the cited references show or teach, even if not 
expressly discussed herein. Although changes to the claims have been made, no acquiescence or 
estoppel is or should be implied thereby; such amendments are made only to expedite 
prosecution of the present application and are without prejudice to the presentation or assertion, 
in the future, of claims relating to the same or similar subject matter. 



If the undersigned attorney has overlooked a relevant teaching in any of the 



references, the Examiner is requested to point out specifically where such teaching may be 
found. In light of the above amendments and remarks. Applicants respectfully submit that all 
pending claims are allowable. Applicants, therefore, respectfully request that the Examiner 
reconsider this application and timely allow all pending claims. The Examiner is encouraged to 
contact the undersigned by telephone to discuss the above and any other distinctions between the 
claims and the applied references, if desired. If the Examiner notes any informalities in the 
claims, the Examiner is encouraged to contact the undersigned by telephone to expediently 
correct such informalities. 
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